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(54) Authentication and access control system 

(57) A system an(d method provide authentication 
for electronic transactions. They involve inputting smart 
card information from a smart card (101) into a payment 
enabled device (1070 and inputting an identification 
number into the payment enabled device. The smart 



card information and the identification number are then 
authenticated (200). Payment information is then sent 
from a server to a desired location after authenticating 
the smart card information and identification number. 
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Description 

[0001] The present invention relates to authentication 
of electronic transactions, for example payment trans- 
actions which are authenticated by use of an EMV 
SmartCard, The disclosure in the present application is 
related to the disclosures in commonly assigned and co- 
pending US patent application no. 09/688,270, filed on 
1 1 October 2000, entitled "PAYMENT ROAMING - PAY- 
MENTS THROUGH VARIOUS NETWORK INSTITU- 
TIONS WITHOUT REGARDS TO TIME OR LOCA- 
TIONS OF THE PAYMENT APPLIANCES", which 
claims priority from US provisional patent application no. 
60/229,274, filed on 30 August 2000, entitled "PAY- 
MENT ROAMING PROCESS". 

[0002] Paying by a payment card (e.g., VISA, Master- 
card, EMV, American Express, etc.) is very common, 
which usually requires a point-of-sale (POS) device, a 
card-issuing bank, an acquirer bank, and a merchant at 
bank. Swiping a payment card through a POS device 
initiates a payment transaction. The card-issuing bank 
issues the card to the customer, and each time the cus- 
tomer uses the card to make payments, the card-issuing 
bank pays for the customer by authorising the acquirer 
bank to transfer the payment amount from the card-is- 
suing bank to the merchant bank. The card-issuing bank 
later bills the customer, usually once a month. Typically, 
the acquirer bank charges the merchant a certain fee 
for processing a payment transaction. 
[0003] An alternative to using standard credit cards is 
to use a smart card, which is a plastic card that includes 
a computer chip embedded inside. An example of a 
smart card is an EMV card, which is the standard for 
Europe, and stands for Europay, Mastercard, VISA. 
These types of cards are designed to be used for phys- 
ical payment, that is being swiped or scanned at a POS 
terminal. The chip includes identification and authenti- 
cation information that is stored therein. 
[0004] Mobile telephones have also been used in pay- 
ment transactions. In one approach, a user uses a cel- 
lular telephone to dial a telephone number associated 
with a vending machine to send payment information to 
that machine and buy products and services from that 
machine. The user then receives the vending-machine- 
transaction bill through the bill for the cellular telephone 
service provider. These telephones may include a web 
identification module (WIM) which would be used to ac- 
tive remote payment. However, such payment may only 
be made through the existing telephone account. 
[0005] Other methods of payments using cards in- 
clude using a PC connecting to the Internet, using a set- 
top box provided by a service provider, and so on. Pay- 
ment by credit cards over the Internet may not be safe. 
Presently, a customer may provide credit card informa- 
tion to a website to buy products/services. However, it 
is difficult for the customer to determine whether that 
website is from a real merchant or from a fraudulent mer- 
chant. Similarly, a merchant does not know for sure 
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whether the customer is using their own card, or is using 
a stolen or fake card. Due to the high risk of fraud, a 
merchant has to pay high fees for the acquirer bank to 
process the payments. These high fees are in turn 

5 passed onto the consumer. A customer may include au- 
thentication keys and certificates in their PC for better 
secured communications over the Internet. However, 
this requires complicated and heavy loading of authen- 
tication software and logistic information into the cus- 

10 tomer's PC. Furthermore, the authentication software 
may be costly, and if the customer upgrades his disk- 
drive or his PC, then he must reload the software. The 
emerging trend is to get payment information including 
payment authentication keys and certificates from a 

15 payment wallet hosted on a web-based server or wallet. 
This requires that only the owner of the virtual wallet 
have access to that wallet. 

[0006] The virtual wallet could comprise many differ- 
ent virtual credit cards, e.g. Visa, Mastercard, Shell 

20 gasoline card. etc. The virtual wallet is distinct from an 
EMV card in that the EMV card is a physical card, while 
the virtual wallet is stored on an electronic medium. The 
medium may be a computer, e.g., PC or Macintosh™. 
The medium may also be a remotely located server that 

25 is reachable via the Internet. This type of medium is 
known as a hosted wallet server. A hosted wallet has 
the payment capability, e.g., software, crypt-engine, 
etc., located at the server. The hosted wallet would allow 
a user to access their virtual wallet from any public com- 

30 puter, e.g., a computer kiosk, a cyber-cafe, a work/office 
computer, etc. The user accesses the hosted wallet via 
software interface known as a portal. Thus, a user may 
make both micro-payments and macro-payments from 
any Internet connected computer. Micro-payments are 

35 relatively small funds that are paid for one time purchas- 
es, e.g., food from a vending machine, a CD, a book etc. 
Macro-payments are relatively large funds that are paid 
for either one time purchases, e.g., a new car or appli- 
ance, or reoccurring purchases, e.g., monthly utility 

40 bills, monthly credit card bills, monthly mortgage bills, 
etc. For example, PALMX users can log on to palmx.net 
and disperse payment. 

[0007] The virtual wallet has problems similar to that 
of the Internet, namely the problem of authentication. It 

45 is difficult for the wallet user to determine whether the 
website that payment is being sent to is that of a real 
merchant or a fraudulent merchant. Similarly, a website 
or merchant does not know for sure whether the wallet 
user is using their own wallet, or is using a stolen or fake 

50 card. 

[0008] The present invention seeks to provide im- 
proved authentication of transactions. 
[0009] According to an aspect of the present inven- 
tion, there is provided a method of authenticating an 
55 electronic transaction as specified In claim 1 . 

[0010] The present invention is directed to a system 
and method which provide authentication for electronic 
transactions. The preferred embodiment involves input- 
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ting smart card information from a smart card into a pay- 
ment enabled device and inputting an identification 
number into the payment enabled device. The smart 
card information and the identification number are then 
authenticated. Payment information is then sent from a 
server to a desired location after authenticating the 
smart card information and identification number. 
[0011] According to another aspect of the present in- 
vention, there is provided a system for authenticating a 
transaction as specified in claim 8. 
[0012] Embodiments of the present Invention are de- 
scribed below, by way of example only, with reference 
to the accompanying drawings, in which: 

FIGURE 1 depicts a preferred embodiment of the 
invention of the smart card being used to authenti- 
cate a transaction; and 

FIGURE 2 depicts a preferred embodiment of the 
authentication of the smart card and the cardholder. 

[0013] The described embodiment is directed to a 
system and method which provides authentication for 
hosted wallet transactions. This allows more secure 
payment when using the Internet, cellular phone, per- 
sonal data assistants (PDAs), a set-top box, kiosk, a 
vending machine, a POS device, or other public and/or 
private device, so long as the device allows access to 
the user's portal for payment from the hosted wallet. 
Thus, the system can provide security for world-wide 
payment capability, as well as virtual world-wide pay- 
ment capability. This allows for payment to be made for 
any type of goods or services, e.g. consumer goods, 
food, travel expenses, meals, utility services, doctor vis- 
its, car payments, loan payments, etc. 
[0014] The system preferably uses a smart card to 
provide the authentication, and more preferably the 
EMV SmartCard. Smart cards are designed to provide 
physical payment, i.e. a user or merchant swiping or 
scanning the smart card across a POS terminal, just like 
a debit card or a credit card. This allows a user to pur- 
chase goods or services like a debit or credit card but 
with more security. The security of the smart card is pro- 
vided by four functionalities or capabilities of the smart 
card. The first capability is that the smart card can be 
fully authenticated by the POS terminal. The second ca- 
pability is that the smart card can be validated off-line, 
meaning that the smart card can be validated by a user 
inputted personal identification number (PIN) code. The 
third capability is that since the smart card has intelli- 
gence via its embedded processor, the smart card has 
more functionality for risk management and therefore 
can take more control of the risk of the transaction. Thus, 
the issuing bank of the smart card can have more deci- 
sion making power in allowing transactions. The fourth 
capability is that the smart card can electronically sign 
transactions and serve as proof of transactions. The 
preferred system makes use of the first two capabilities 
of the smart card. 



[0015] The preferred system uses the capabilities of 
the smart card to provide authentication for hosted wal- 
let transactions. A user would access their wallet and 
then provide their smart card for authentication. The first 
5 functionality of the smart card would establish the au- 
thenticity of the hosted wallet account. A valid smart 
card would indicate that the wallet account (as well as 
the account owner) associated with the smart card is 
also valid. The second functionality of the smart card 

10 would establish the authenticity of the user, as only the 
smart card owner (or authorised agent thereof) would 
know the PIN number. The authentication of the mer- 
chant may be done by the hosted wallet server. This 
server may compare merchant Information against lists 

'5 of known and accepted merchants, as well as lists of 
fraudulent merchants. The use of the smart card allows 
for the hosted wallet to be used for payment transaction 
in a secure and reliable manner. Note that with the pre- 
ferred system payment is being provided by the hosted 

20 wallet server and not the smart card, thus the smart card 
is not being used for payment but rather for authentica- 
tion of the user and the wallet account. In other words 
the smart card Is being used to unlock payment from a 
payment server. 

25 [0016] Thus the preferred system enables remote 
identification of a user or consumer by using the user's 
smart card, e.g. EMV card. This remote identification is 
preferably used by a consumer to access their wallet 
server or payment proxy server that contains their serv- 

30 er-based wallet. This wallet contains payment informa- 
tion enabling payment transactions over the virtual 
world (wired or wireless Internet). The payment trans- 
action is preferably made via the 3 Domain SET/SSL 
standard from Visa and Mastercard. Consequently, the 

35 preferred system uses the remote identification to acti- 
vate a 3D transaction from the wallet server. The use of 
the smart card provides the wallet server proof that the 
remote user that is attempting to activate a payment en- 
gine is an authorised user. 

40 [0017] FIGURE 1 depicts a preferred embodiment of 
system 1 00 that uses a smart card 1 01 , e.g. EMV Smart- 
Card, to authenticate or identify the cardholder to the 
server based wallet or hosted wallet 102. After a user 
or consumer has decided to make a purchase of goods 

45 or a service, the user or merchant sends a payment re- 
quest to the server that hosts the user's wallet. The pay- 
ment request preferably contains information regarding 
the user and the merchant, e.g. user identification 
number and/or merchant identification number, along 

50 with a payment amount. The payment request also pref- 
erably includes type of payment information, e.g. credit 
account, debit account, pre-paid account, loyalty point 
account (e.g. frequent fiyer miles). Other information 
such as a description of goods or services being pur- 

55 chased may also be included. 

[0018] The request may originate from a retail point 
of sale (POS) terminal 104 which is typically located at 
a merchant's store. The request may also originate from 
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a smart phone 1 05 that belongs to the consumer or the 
merchant. The request may also originate from a set- 
top box 106, which is a scaled down computer, that al- 
lows user to access the Internet from a television. The 
request may also originate from any public or private 
payment enabled device 1 07. Public devices may be at- 
tended by staff or unattended, but are devices that are 
accessible by the general public. For example, attended 
public devices may include kiosks, POS terminals, com- 
puters, and/or similar devices, white unattended public 
devices may include kiosks, vending machines, parking 
meters, newspaper machines, and/or similar devices. 
Private devices are those that belong to the consumer/ 
user and may include personal data assistants (PDAs), 
computers, set-top devices, telephones, cell phones, 
and/or similar devices. Note that devices such as PDAs, 
and smart phones can send the request from any loca- 
tion, e.g., using wireless (cellular or satellite) communi- 
cations, and thus do not have to be a particular location 
to send payment requests. 

[001 9] Prior to completion of the request by the hosted 
wallet server 102, the user and the smart card are pref- 
erably authenticated. An example of a preferred embod- 
iment 200 of authentication is depicted in FIGURE 2. 
The smart card is inserted into the card reader of the 
request device 104, 105, 106 or 107, which wakes up 
the smart card 201. The smart cart is preferably then 
read 202 and authenticated 203 by the request device 
104, 105, 106 or 107. Alternatively, the smart card may 
send an authentication message to the wallet server, 
and the wallet then authenticates 203 the smart card, 
as a 'rear smart card based on the message. The device 
104-107 requests the PIN from the user 204. The pin is 
then preferably sent to the smart card 205, which verifies 
the PIN and authenticates the cardholder (or user or 
consumer) 206 as an authorised user of the smart card. 
The smart card 101 then forms a unique cryptogram, 
which is sent by device 1 04-1 07 to the wallet server 1 02 
for verification. Alternatively, the wallet then requests 
the personal identification number (PIN) from the user 
204. In this case, the PIN message may be sent 205 to 
the wallet for authentication 206. At this point, both the 
smart card and the user have been authenticated and/ 
or verified by the wallet server 102. 
[0020] The wallet then proceeds with the processing 
of the request 207. Note that authentication 200 may 
occur prior to the delivery of the request to the wallet, e. 
g., authentication is performed before the request is 
sent. Also, the authentication may occur concurrently 
with the delivery of the request information to the wallet, 
e.g., the request includes the authentication informa- 
tion. Furthermore, the authentication may occur after 
the request information has been delivered to the wallet, 
e.g., authentication occurs after the request has been 
sent, but before completion of the processing. 
[0021] After authentication, the wallet on the wallet 
server 102 processes the transaction. Such processing 
is more fully explained in the co-pending US patent ap- 



plication no. 09/688,270, filed on 11 October 2000, en- 
titled "PAYMENT ROAMING - PAYMENTS THROUGH 
VARIOUS NETWORK INSTITUTIONS WITHOUT RE- 
GARDS TO TIME OR LOCATIONS OF THE PAYMENT 

5 APPLIANCES", which is hereby incorporated herein by 
reference in its entirety. The remainder of FIGURE 1 de- 
picts a preferred embodiment for such processing. The 
wallet server 102 sends at least a portion of the request 
to the merchant's website (or server), e.g., merchant. 

10 com 111, via the Internet 109. Encryption 110, e.g.. Se- 
cure Electronic Transaction (SET) protocols, provides a 
secure link between the wallet server 102 and the mer- 
chant server 111. The merchant server then generates 
a payment request based on the product or service re- 

15 quest from the wallet server. The payment request is 
passed to the acquirer's gateway 112, via the Internet 
109, and secured by encryption 110. The acquirer's 
gateway 112 is the server of the bank selected by the 
merchant to manage payment requests. The acquirer's 

20 gateway 1 1 2 then contacts the appropriate financial in- 
stitution 103, e.g., VISA or MASTERCARD or the like, 
of the user or cardholder. Transactions between gate- 
way 112 and institution 1 03 may be delivered by a ded- 
icated line, Internet or Intranet. The merchant server 

25 may issue a transaction paid message 108 or digital re- 
ceipt to the user device 104-107 via the Internet 109. 
The merchant server may also issue a transaction paid 
message or digital receipt to the user's wallet in wallet 
server 102. Such receipts may be used as proof of pur- 

30 chase, for payment history, and/or for account reconcil- 
iation. 

[0022] Note that some transactions may begin at the 
merchant server. For example, a person may be surfing 
the Internet, and purchase something from the mer- 

35 chant.com site. In such cases the authentication will oc- 
cur through the merchant.com site to the hosted wallet. 
[0023] Further note that the various hand-shaking 
messaging and verif ication messaging that would occur 
between the wallet server, the merchant server, the ac- 

40 quirer's gateway and the financial institution is not 
shown for the sake of simplicity. 

[0024] When implemented in software, the elements 
of the preferred system are essentially the code seg- 
ments to perform the necessary tasks. The program or 

45 code segments can be stored in a processor readable 
medium or transmitted by a computer data signal em- 
bodied In a carrier wave, or a signal modulated by a car- 
rier, over a transmission medium. The "processor read- 
able medium" may include any medium that can store 

50 or transfer information. Examples of the processor read- 
able medium include an electronic circuit, a semicon- 
ductor memory device, a ROM, a flash memory, an eras- 
able ROM (EROM), a floppy diskette, a compact disk 
CD-ROM, an optical disk, a hard disk, a fibre optic me- 

55 dium, a radio frequency (RF) link, etc. The computer da- 
ta signal may include any signal that can propagate over 
a transmission medium such as electronic network 
channels, optical fibres, air, electromagnetic, RF links, 
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etc. The code segments may be downloaded via com- 
puter networks such as the Internet, Intranet, etc. 
[0025] The disclosures in United States patent appli- 
cation no. 09/882,978, from which this application 
claims priority, and in the abstract accompanying this 
application are incorporated herein by reference. 



Claims 

1. A method of authenticating an electronic transac- 
tion including the steps of: 

inputting smart card information from a smart 
card (101) into a payment enabled device 
(107): 

inputting an identification number into the pay- 
ment enabled device; 

authenticating (203) the smart card informa- 
tion; 

authenticating (206) the identification number; 
and 

sending payment information from a server 
(1120 to a desired location after authenticating 
the smart card information and authenticating 
the identification number. 
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8. A system for authenticating a transaction Including 
means (104-106) for Inputting smart card informa- 
tion from a smart card (101); means for inputting an 
identification number into a payment enabled de- 
vice (107); means for authenticating the smart card 
information; means for authenticating the identifica- 
tion number; and means for sending payment infor- 
mation from a remote server (112) to a desired lo- 
cation after authenticating the smart card informa- 
tion and authenticating the identification number. 

9. A system as in claim 8, wherein the payment ena- 
bled device is a private payment enabled device or 
a public payment enabled device. 

10. A system as in claim 8. wherein the payment ena- 
bled device (1 07) is a kiosk, a point of sale terminal, 
a computer, a vending machine, a parking meter, a 
newspaper machine, a personal data assistant, a 
set-top box, a telephone or a cell phone. 



25 



A method as in claim 1, wherein the payment ena- 
bled device is a private payment enabled device or 
a public payment enabled device. 



30 



3. A method as in claim 1 , wherein the payment ena- 
bled device (107) is a kiosk, a point of sale terminal, 
a computer, a vending machine, a parking meter, a 
newspaper machine, a personal data assistant, a 35 
set-top box, a telephone or a cell phone. 

4. A method as in any preceding claim, wherein the 
step of authenticating the smart card information 
(203) is performed by the payment enabled device 40 
(107) or by the server (112). 

5. A method as in any preceding claim, wherein the 
step of authenticating the identification number 
(206) is performed by the smart card (101). 45 

6. A method as in any preceding claim, wherein the 
electronic transaction is payment for at least one of 
a good and a service provided by a merchant. 

50 

7. A method as in claim 6, wherein the desired location 
is: 



the merchant; 

a merchant server that is used by the merchant; ss 
or 

a financial institution that is used by the mer- 
chant. 
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